chore(deps): pin pyasn1 >=0.6.4 and cryptography >=50.0.0 to fix high-severity Dependabot alerts - #2310
Conversation
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
|
👋 @devin-ai-integration[bot] |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe project metadata updates version constraints for ChangesRuntime dependency updates
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…t alert Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
| urllib3 = ">=2.7.0,<3.0.0" | ||
| idna = ">=3.15,<4" # transitive dependency via requests, pinned to address CVE-2025-46816 | ||
| pyasn1 = ">=0.6.4,<0.7" # transitive dependency via google-auth/pyasn1-modules, pinned to address BER/CER/DER decoder DoS advisories | ||
| cryptography = ">=50.0.0,<51" # transitive dependency via google-auth/azure-storage-blob, pinned to address CVE-2026-69247 (PKCS#7 Bleichenbacher oracle) |
There was a problem hiding this comment.
Just wondering if this might be too restrictive for users as this is a common library.
Should we instead upgrade libraries so we can rely on newer versions?
There was a problem hiding this comment.
Fair concern — and upgrading parents won't help here. The advisory (GHSA-g6cj-pr64-35w5) affects cryptography >=44.0.0,<50.0.0 with no backport: 50.0.0 (released 2026-07-31) is the only fixed version. So any floor that satisfies Dependabot is "latest major, 9 days old". No parent of ours caps cryptography (google-auth >=38.0.3, azure-storage-blob >=2.1.4, snowflake-connector-python >=46.0.5, no constraint in the dbt adapters), so the pin doesn't conflict today — but it does force every edr install into a brand-new major of a very common library, which in a shared dbt env is exactly the friction you're describing.
Worth noting the exposure: the vuln is a Bleichenbacher oracle in PKCS#7 EnvelopedData decryption (pkcs7_decrypt_der/pem/smime). We never decrypt PKCS#7 — cryptography reaches us only as a transitive TLS/JWT dependency of google-auth, azure-storage-blob and snowflake — so this is not exploitable in elementary.
Three options, happy to push whichever you prefer:
- Drop the
cryptographypin entirely and dismiss the alert as "vulnerable code not in path" (my recommendation, given the above). - Keep the floor but drop the
<51cap →cryptography = ">=50.0.0", so users aren't blocked from future majors. - Leave as-is.
pyasn1 in the same diff is unaffected by this discussion — 0.6.4 is a patch on the current line and closes three real DoS advisories.
There was a problem hiding this comment.
Ok so let do (2) - drop the gap.
Also for other similar transitive deps limitations.
There was a problem hiding this comment.
Done in df617a6 — dropped the upper caps on all the transitive-only pins, so they're pure security floors now:
-urllib3 = ">=2.7.0,<3.0.0"
-idna = ">=3.15,<4"
-pyasn1 = ">=0.6.4,<0.7"
-cryptography = ">=50.0.0,<51"
+urllib3 = ">=2.7.0"
+idna = ">=3.15"
+pyasn1 = ">=0.6.4"
+cryptography = ">=50.0.0"Each of these already has its major bounded by the parent that actually depends on it (requests caps urllib3<3 and idna<4, pyasn1-modules caps pyasn1<0.7), so the caps were redundant and only served to block users from future majors. Left requests, dbt-core etc. untouched since those are real direct deps where the major bound is intentional.
…1, cryptography, urllib3) Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pyproject.toml`:
- Line 31: Update the inline comment on the idna dependency declaration to
reference CVE-2026-45409 and GHSA-65pc-fj4g-8rjx, and state that version 3.15 is
the security floor; remove the incorrect CVE-2025-46816 reference while
preserving the dependency constraint.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Summary
Clears all four open high-severity Dependabot alerts in this repo. Both packages are transitive-only and there is no lock file, so the fix follows the existing
idnaprecedent: explicit floors on the transitive dependency inpyproject.toml.pyasn1(3 alerts): BER/CER/DER decoder DoS via unbounded long-form tag IDs, quadratic complexity in OBJECT IDENTIFIER / RELATIVE-OID processing, uncontrolled resource consumption converting decoded REAL values. Upper bound<0.7becausepyasn1-modulespinspyasn1 <0.7.cryptography(1 alert, CVE-2026-69247 / GHSA-g6cj-pr64-35w5, vulnerable>=44.0.0,<50.0.0): PKCS#7EnvelopedDataBleichenbacher oracle. No dependent capscryptography(google-auth >=38.0.3,azure-storage-blob >=2.1.4,snowflake-connector-python >=46.0.5), so the floor resolves cleanly — verified with a scratchpoetry lock(Poetry 1.8.5, matching the repo) over the full dependency set including the warehouse extras.Link to Devin session: https://app.devin.ai/sessions/9b1b941648704776a28d6b134f3a667e
Summary by CodeRabbit